Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Angular from visualize #20295

Merged
merged 4 commits into from
Jul 9, 2018

Conversation

ppisljar
Copy link
Member

@ppisljar ppisljar commented Jun 28, 2018

removes angular from visualize directive and turns it into a class.

From now on the data fetching (that was earlier part of the <visualize> directive) will be triggered by the visualize loader directly, which then renders or updates the Visualization React component with the fetched data.

This PR removes Angular completely from out central rendering infrastructure 🎉

@ppisljar ppisljar added WIP Work in progress Feature:Visualizations Generic visualization features (in case no more specific feature label is available) blocked labels Jun 28, 2018
@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch 5 times, most recently from 723fe1b to 71e3704 Compare July 5, 2018 05:50
@ppisljar ppisljar removed the blocked label Jul 5, 2018
@elastic elastic deleted a comment from elasticmachine Jul 5, 2018
@elastic elastic deleted a comment from elasticmachine Jul 5, 2018
@elastic elastic deleted a comment from elasticmachine Jul 5, 2018
@elastic elastic deleted a comment from elasticmachine Jul 5, 2018
@elastic elastic deleted a comment from elasticmachine Jul 5, 2018
@elastic elastic deleted a comment from elasticmachine Jul 5, 2018
@elastic elastic deleted a comment from elasticmachine Jul 5, 2018
@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch from 71e3704 to c0ccec2 Compare July 5, 2018 06:32
@elasticmachine
Copy link
Contributor

💔 Build Failed

@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch 2 times, most recently from 8d1192c to 457345d Compare July 5, 2018 08:12
@elasticmachine
Copy link
Contributor

💔 Build Failed

@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch 2 times, most recently from 0ce3f31 to 3bc7801 Compare July 5, 2018 09:58
@elasticmachine
Copy link
Contributor

💔 Build Failed

@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch 2 times, most recently from b304555 to 266bae8 Compare July 5, 2018 11:29
@elasticmachine
Copy link
Contributor

💔 Build Failed

@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch from 266bae8 to 9624da8 Compare July 5, 2018 13:04
@ppisljar ppisljar added the review label Jul 5, 2018
Copy link
Member

@markov00 markov00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Tested on chrome/osx.
Just a minor comment

this._listeners = new EventEmitter();
// Listen to the first RENDER_COMPLETE_EVENT to resolve this promise
this._firstRenderComplete = new Promise(resolve => {
this._listeners.once(RENDER_COMPLETE_EVENT, resolve);
});
this._element.on('renderComplete', () => {
this._element.addEventListener('renderComplete', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems that we are not removing the event listener of this renderComplete event in the destroy. Is it fine?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would agree, I think we should deregister this properly.

@@ -17,4 +17,4 @@
* under the License.
*/

import './visualize';
import './loader';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't make much sense, since loader itself just exports some classes. We should either put an export * from './loader'; here in case we want to enable importing getVisualizeLoader from ui/visualize directly, or just remove the whole index.js file.

this._listeners.emit(RENDER_COMPLETE_EVENT);
});

this._loaded = false;
this._destroyed = false;

This comment was marked as resolved.

});
};

_fetchAndRender = _.debounce((forceFetch) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Give this a default value = false for better readability.

@@ -17,7 +17,11 @@
* under the License.
*/

import _ from 'lodash';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should rather start using named imports for that (since it would potentially allow for better tree shaking - and imho also improves readability): import { debounce } from 'lodash';

}

/**
* Destroy the underlying Angular scope of the visualization. This should be
* called whenever you remove the visualization.
*/
destroy() {
this._scope.$destroy();
this._destroyed = true;
this._vis.removeListener('reload', this._reloadVis);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there might be a tiny chance, that we're actually currently have triggered a fetchAndRender that's still in debounce while we're destroying. I think in that case we should cancel the debounce. It seems the method returned from the debounce call above should have a property cancel so that we can call this._fetchAndRender.cancel() here.

* specific language governing permissions and limitations
* under the License.
*/
import _ from 'lodash';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, could we use named imports, please.


const handlerParams = {
...props,
forceFetch: forceFetch,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎨 Just forceFetch would be enough.

this._previousVisState = this._vis.getState();
this._previousRequestHandlerResponse = requestHandlerResponse;

this._visData = canSkipResponseHandler ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎨 I would prefer the following version slightly:

if (!canSkipResponseHandler) {
  this._visData = await Promise.resolve(this._responseHandler(this._vis, requestHandlerResponse));
}

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

this._responseHandler = getHandler(responseHandlers, responseHandler);
}

fetch = async (props, forceFetch = false) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that can use the regular function syntax async fetch(props, forceFetch = false) { since we don't seem to call this anywhere in a weird this-overwriting way.

this.props.searchSource.cancelQueued();
this._vis.requestError = e;
if (isTermSizeZeroError(e)) {
return toastNotifications.addDanger(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should really move this to a more sane place (though not necessarily in this PR, but we should start thinking about what a sane place could be).

Copy link
Contributor

@timroes timroes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks now good for me. Tested it out (Chrome, Linux) with different combinations of visualizations/dashboards/etc couldn't find any issue.

LGTM, as long as it's merged after #20480 has been reviewed, merged, and this one rebased on it.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch from f236803 to b24c043 Compare July 9, 2018 13:32
@elasticmachine
Copy link
Contributor

💔 Build Failed

@ppisljar ppisljar force-pushed the fix/visualizeRemoveAngular branch from b24c043 to 3a76eb6 Compare July 9, 2018 17:57
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@ppisljar ppisljar merged commit fffa3d4 into elastic:master Jul 9, 2018
@ppisljar ppisljar deleted the fix/visualizeRemoveAngular branch July 9, 2018 20:39
ppisljar added a commit to ppisljar/kibana that referenced this pull request Jul 11, 2018
@LeeDr
Copy link

LeeDr commented Jul 23, 2018

Just a note that this PR apparently broke auto refresh on visualizations and dashboards.

@timroes
Copy link
Contributor

timroes commented Jul 24, 2018

@LeeDr see #20813 that was created a week ago, we already marked it as a blocker for 6.4.0 after syncing with Sharing and Discovery about the time picker issues.

@timroes timroes mentioned this pull request Jul 30, 2018
@ppisljar ppisljar restored the fix/visualizeRemoveAngular branch September 26, 2018 10:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Feature:Visualizations Generic visualization features (in case no more specific feature label is available) review v6.4.0 v7.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants